app/(tabs)/calendar/hooks/useCalendarState.ts (2)

37-46: handleDateChange : vous pouvez le rendre vraiment “stable” (perf) via une mise à jour fonctionnelle.
Aujourd’hui la dépendance [weekNumber] fait recréer le callback à chaque changement de semaine. Une MAJ fonctionnelle évite ça et réduit les re-renders en cascade.

Proposition de diff

-  const handleDateChange = useCallback(
-    (newDate: Date) => {
-      setDate(newDate);
-      const newWeekNumber = getWeekNumberFromDate(newDate);
-      if (newWeekNumber !== weekNumber) {
-        setWeekNumber(newWeekNumber);
-      }
-    },
-    [weekNumber]
-  );
+  const handleDateChange = useCallback((newDate: Date) => {
+    setDate(newDate);
+    const newWeekNumber = getWeekNumberFromDate(newDate);
+    setWeekNumber(prev => (prev !== newWeekNumber ? newWeekNumber : prev));
+  }, []);

---

76-88: onMomentumScrollEnd : OK, mais attention aux recréations fréquentes (dépend de currentIndex).
Si l’objectif est de stabiliser les handlers pour la perf, un pattern “ref + setState fonctionnel” peut éviter d’avoir currentIndex en dépendance.

app/(tabs)/calendar/index.tsx (2)

39-51: timetableMap : bonne idée, mais typez la Map pour éviter le Map<any, any> implicite.
En TS, ça aide aussi à sécuriser day.courses et les .get(...).

Proposition de diff (typing)

-  const timetableMap = useMemo(() => {
-    const map = new Map();
+  const timetableMap = useMemo(() => {
+    const map = new Map<number, (typeof timetable)[number]["courses"]>();

---

74-80: extraData : OK, mais timetable.length ne couvre pas les changements de contenu à longueur constante.
Si timetable peut muter “à longueur égale” (ex: cours modifiés), vous risquez de ne pas rafraîchir certaines cellules selon les optimisations FlatList. À minima, vérifiez que timetable est toujours remplacé immuablement par le hook (nouvelle référence) quand le contenu change.

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro